Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000083_owner-urn-ietf _Wed Oct 23 11:05:08 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA26303 for urn-ietf-out; Wed, 23 Oct 1996 11:05:08 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA26298 for <[e-mail]>; Wed, 23 Oct 1996 11:05:06 -0400
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA16561  (mail destined for [e-mail]); Wed, 23 Oct 96 11:05:05 -0400
Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA19847; Wed, 23 Oct 1996 09:05:03 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 2.2 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Oct 1996 09:12:39 -0600
To: [e-mail]
From: Ron Daniel <[e-mail]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: URN Mailing list <[e-mail]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Ron Daniel <[e-mail]>
Errors-To: [e-mail]

Thus spoke YON - Jan C. Hardenbergh (at least at 07:06 AM 10/23/96 -0400)
>Ron Daniel wrote:
>> Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500)
>> >Is the intent that "urn:" be optional within more contexts, such
>> >as within HTML documents following "HREF="?
>>
>> That is *my* intent, although I would be interested in feedback
>> from the list on the subject.

>>From a VRML point of view, we need it to be there. While we have not
>quite written it in to the spec, yet. There is a notion that one can
>create extenions to VRML and have them defined by a URN. The browser
>can then use native implementations for URNs it recognizes.

This is to solve the generic telephone problem?
Can you please give an example of the URNs you are thinking of?


>I don't understand how it can be optional. Is it that it is the
>URN resolution is the default protocol? How do we know that there
>is not an isbn: protocol?

The URN syntax says [urn:] NID ':' NSS
In other words, the urn: is *always* followed by a Namespace Identifier.
It is my thinking (which I believe is shared by many others on this list)
that new namespaces go through the same sort of review process as new
URL schemes do. Therefore, we would have a mechanism for ensuring that
URN namespace IDs did not use the same character string as a URL protocol.
That is how we would know there is not an isbn: protocol, as opposed to
an isbn: namespace.

Given that URNs have to provide a namespace ID, and that the namespace ID
will be distinct from URL protocols, the urn: prefix does not add a
great deal of information. Since it has been the source of religious
controversy in the past, I suggested making it optional. (I also
like using isbn: as an example, rather than urn:isbn:).


What I would like to see happen is that a URN resolution algorithm
becomes the "unknown scheme" error handler in browsers. Browsers
continue to have a lookup table of schemes and function pointers
to handle those schemes. When an unknown scheme is encountered, they
can assume it is a new URN namespace and try to resolve it that way.
The URN resolver would then report an unknown namespace error, or
send back info on "speak HTTP to this resolver to get the resource".

Later,
Ron Daniel Jr.                       email: [e-mail]
Advanced Computing Lab               voice: [phone]
MS B287                                fax: [phone]
Los Alamos National Laboratory        http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA  87545    obscure_term: "hyponym"